Large software systems are normally divided into multiple subsystems that are developed as individual components. Interactions between these subsystems and/or components must be properly depicted in order to provide for smooth deployment. Moreover, in multi-layered systems, individual components of the application have their equivalent parts deployed over multiple layers. For example, components might be distributed across databases in a resource manager layer. Information about the deployment of parts of each component must be known in other layers so as to have accessibility within and across components for each layer and across layers.
Normally component interactions and deployment are depicted using Unified Modeling Language (UML) diagrams and deployment is done manually. Because of this, for multi-layered applications, topology selection becomes a most problematic task for application deployment. Various factors like security, performance, throughput, scalability, availability, maintainability and session management should be considered during the review of requirements so as to formulate the topology selection criteria.
A related issue, hardware sizing, is sometimes arrived at after making an estimate about the size of the applications and the appropriate topology selection. In contrast, there may be situations where topology selection is already constrained by the existing hardware. While fine-tuning the live applications for factors such as those mentioned above, a trial and error approach to arrive at a final optimal solution is unavoidable. When the number of users increases, it is necessary to add extra server instances to cater to the increased user requests and also to load balance across the machines.
In a multi tier system, it is possible to deploy software artifacts of different layers in a multitude of permutations and combinations. This is compounded by the fact that the hardware platform can be distributed with each platform catering to a subset of the user groups. One example in which this is required is with large organizations that are located across the globe. By contrast, for small organizations, there is a need to deploy the application in a minimum mode configuration with all layers resident on the same physical hardware. During deployment, the application architecture in terms of component interaction, the organizational structure in terms of functions performed in different organization units, as well as the hardware topology in terms of servers hosting different layers, must all be balanced and correct for the proper functioning of the application. The use of manual systems to deploy such complex applications with a lot of interdependencies is fraught with dangers (such as missed elements), and do not explicitly formalize software deployment and roll out.
Additionally, current practices and tools for software deployment deal with only the technical aspects of deploying software onto the respective hardware structures, and the administration of access specifications to business functions and users is disjoint. Moreover, when there is a reorganization and consequent redeployment, existing practices are cumbersome and are dependent on detailed manual documentation of deployment maps. The current set of technologies and distributed processing schemes make the task even tougher.